…n on Mali

…rToImage2 uploads

…isk cache path

…ped with CPU fallback

WRAPPER_ASTC_BLOCK=8x8 stores emulated BC textures as ASTC 8x8 (2 bpp,
a quarter of 4x4's footprint) instead of the default 4x4. Each 8x8 block
packs a 2x2 group of BC blocks and fits a 4x4 weight grid to the 64 ideal
texel weights via the infill pseudo-inverse. Both the CPU encoder and the
transcode compute shader now emit the 8x8 form (selected per-dispatch by an
astc8 push constant); the shader's float weight-fit is bit-identical to the
CPU double encoder, validated offline over 8000 blocks against Mesa's ASTC
decoder. This removes the load-time memory thrash that 4x4 hit on Mali while
keeping the GPU transcode path, so large BC7 texture sets upload fast and
stay small.

The GPU compute transcode is correct in isolation — its BC7 decode is
bit-identical to bcdec across all eight modes and the ASTC encode matches the
CPU encoder — but injecting compute dispatches inline into vkd3d's command
buffers corrupts Hades's launch-screen rendering (the screen goes black).
The boot is dominated by the game's own package load rather than by transcode,
so the GPU path saves no meaningful time here. Default WRAPPER_BCN_GPU to 0
(CPU, correct everywhere); set WRAPPER_BCN_GPU=1 to opt back into the GPU path.

WRAPPER_DIAG=1 emits a self-contained report at vkCreateDevice, to stderr
(logcat) and to WRAPPER_DIAG_FILE: device/driver/engine identity, what the
device NATIVELY supports vs what the wrapper advertises to the D3D layer
(robustness2, vertex_attribute_divisor EXT/KHR, BC/ASTC, forced features),
and the extensions the app requested at device creation. This lets a failing
game on any device be diagnosed from the shared report alone, paired with
app-side VKD3D_DEBUG=warn / DXVK_LOG_LEVEL=info / WINEDEBUG=+vulkan. Off
unless WRAPPER_DIAG is set; zero cost otherwise.

Write the diagnostics report to
/data/data/app.gamenative/files/imagefs/usr/tmp/wrapper_diag_<appid>.txt,
named by WRAPPER_DIAG_APPID (falling back to the sanitized executable name)
so multiple games each get their own file instead of clobbering one. The
chosen path is echoed to logcat; WRAPPER_DIAG_FILE still overrides it.

A single launch creates several VkDevices across processes (zink GL infra,
DXVK, vkd3d) that share one per-game report file. Opening it with "w"
truncated per process, so they clobbered each other and the D3D device's
block -- the one needed to debug a failing game -- was routinely lost to a
later zink device. Append instead; each block is delimited and names its
engine, and usr/tmp is recreated per launch so the file stays one launch's
worth.

WRAPPER_DIAG_TEX=1 records, for each BCn CPU upload, the real parameters
(source stride, target format, and the destination image's format / extent /
mip count / tiling / usage / flags) and dumps the leading source BC7 bytes plus
our transcode output to wrapper_tex_<appid>.txt. This localizes a corrupt-
texture case (e.g. Xclipse renders BC7 as static even via RGBA-CPU): the
transcode can be verified byte-for-byte offline against the reference decoder,
and any stride/format/tiling mismatch in how the image is uploaded becomes
visible. Off unless set; instruments the CPU path (run with WRAPPER_BCN_GPU=0).

WRAPPER_DIAG_TEX appended to a separate wrapper_tex_<appid>.txt; fold it into
wrapper_diag_<appid>.txt (append) so a report is a single file to grab and share.

One switch: WRAPPER_DIAG=1 captures everything -- device blocks and the
per-upload texture params/byte dumps -- into the single per-game diag file.
No separate flag.

The texture dump only sat in the BCn transcode path, so anything that didn't
reach it -- native passthrough formats, or textures that fail to create before
upload -- was invisible. Add a copy-level log (WRAPPER_DIAG=1) at the entry of
both CmdCopyBufferToImage and CmdCopyBufferToImage2 that records every copy to a
tracked image: requested vs stored format, emulated flag, extent, mip, source
stride, tiling, usage. Appends to the per-game diag file. This makes a missing
texture visible by its absence (it never got copied) and catches non-BCn
corruption too.

…n Xclipse

DXVK 2.5+ fails to initialize on Samsung Xclipse (RDNA) because the driver
exposes neither VK_KHR_maintenance5 nor maxPushConstantsSize >= 256.

Emulate VK_KHR_maintenance5 for D3D clients whose base driver lacks it
(self-limiting: Mali/Adreno expose it natively and are skipped):
- advertise the extension and fake the maintenance5 feature
- unlink VkPhysicalDeviceMaintenance5Features from the real CreateDevice pNext
- implement the new device entrypoints (CmdBindIndexBuffer2,
  GetRenderingAreaGranularity, GetImageSubresourceLayout2,
  GetDeviceImageSubresourceLayout) as prefer-native-else-translate, so they
  forward to the driver where it has maintenance5 and translate where it doesn't
- fold VkBufferUsageFlags2CreateInfo back into the 32-bit usage in CreateBuffer
  (DXVK 2.5+ specifies buffer usage via flags2 and leaves the old field 0)

Bump maxPushConstantsSize to 256 on Xclipse so DXVK 2.6+ stops skipping the
adapter ("does not support 256 of push data"); the underlying RDNA hardware
handles 256 and the driver does not enforce the reported limit at pipeline
creation.

Confirmed: DXVK 2.7.1 runs on Xclipse; no regression on Mali (native
maintenance5, emulation dormant).

WRAPPER_DIAG previously wrote only the wrapper's own capability report to the
file; the vkd3d/DXVK/wine output that actually explains a failure (Heap too
small, device-lost, format rejects, crashes) went to stdout/stderr/logcat
separately, so a shared report was missing half the story. Now, for a D3D
engine, the wrapper redirects the process's stdout+stderr into the diag file
once (at first device creation), and routes its own WRAPPER_LOG lines there too
when WRAPPER_DIAG is set. One per-game file now holds: the faked-extension
decisions, the device-capability report, the texture dumps, and the vkd3d/DXVK
error output -- everything needed to diagnose from a single shared file.